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TECHNICAL FIELD: 

5 

These teachings relate generally to wireless communications systems and, more specifically, to 
procedures for determining a location or a position of a mobile station (MS) within the wireless 
network (NW). 

10 BACKGROUND: 

The following abbreviations are herewith defined. 
3G Third Generation (cellular system) 

A/Gb mode Mode of operation of MS when connected to the core network via GERAN and 
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the A and/or Gb interfaces 




BSC 


Base Station Controller 




BTS 


Base Transceiver Station 




CN 


Core Network 




CRS 


Cell Re-Selection 


20 


CS 


Circuit Switched 




DL 


Down Link (to the MS) 




EDGE 


Enhanced Data rate for Global Evolution 




E-OTD 


Enhanced-Observed Time Difference 




GERAN 


GSM/EDGE Radio Access Network 


25 


GGSN 


Gateway GPRS Support Node 




GMLC 


Gateway Mobile Location Center 




GPS 


Global Positioning System 




GRA 


GERAN Registration Area 




GSM 


Global System for Mobile Communications 


30 


GTP 


GPRS Tunneling Protocol 




HO 


Handover 




EV1SI 


International Mobile Subscriber Identity 




IP 


Internet Protocol 



Mode of operation of MS when connected to the core network via GERAN or 
UTRAN and the Iu interface 





Iur 


A logical interface between two RNC 




Iur-g 


A logical interface between two BSCs 




5 LCS 


Location Services 




ME 


Mobile Equipment 




MM 


Mobility Management 




MS 


Mobile Station 




MSC 


Mobile Switching Center 




10 NAS 


Non- Access Stratum 




PDCP 


Packet Data Convergence Protocol 




PDP 


Packet Data Protocol 


□ 


PDU 


Packet Data Unit 


i 


PS 


Packet Switched 


nJ 


15 QoS 


Quality of Service 


yl 

L 


RAB 


Radio Access Bearer 


o 


RAN 


Radio Access Network 




RANAP 


Radio Access Network Application Ps 


a 


RNC 


Radio Network Controller 




20 RNTI 


Radio Network Temporary Identity 




RR 


Radio Resources 




RRC 


Radio Resource Control 




RRLP 


Radio Resource Location Procedure 




SGSN 


Serving GPRS Support Node 




25 SMLC 


Serving Mobile Location Center 




SRNS 


Serving RNS 




UE 


User Equipment 




UL 


Uplink (from the MS) 



UMTS Universal Mobile Telecommunications System 

30 URA UTRAN Registration Area 

UTRAN Universal Terrestrial Radio Access Network 

VMSC Visited MSC 
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Reference can also be made to 3GPP TR 21 .905 , V4.4.0 (200 1-10), Third Generation Partnership 
Project; Technical Specification Group Services and System Aspects; Vocabulary for 3GPP 
Specifications (Release 4). 

5 Over the period of a decade the GSM standard has evolved from a basic voice service to a wide 
variety of speech and data services. In the 3 GPP Release 5 the functional split between the 
GSM/EDGE Radio Access Network (GERAN) and the core network (CN) will be aligned with 
the functional split between UTRAN and the CN, thereby enabling GERAN to connect to the 
same 3G core network and to provide the same set of services as UTRAN. This functionality 
10 split implies a new architecture for GERAN and significant modifications to the GERAN radio 
u _ protocols. 
I 

Several new interfaces such as Iu and Iur-g are defined for the GERAN architecture. The Iu 
interface is common between UTRAN and GERAN. An Iu-ps and Iu-cs interface is being 
considered, where Iu-ps is the interface targeted for the packet switched (PS) domain, and Iu-cs 
is the interface targeted towards the circuit switched (CS) domain. Both of these interfaces will 
be supported by the GERAN specifications. The Iur-g is the interface between two GERANs, 
and supports signaling information between them (note that the Iur-g is currently planned to 
support only the control plane procedures of Iur). 

A Mobile Station (MS) can be attached to the core network through either the Iu-cs or Iu-ps, or 
through both the Iu-cs and Iu-ps interfaces. The MS can also be attached to the CN through the 
legacy interfaces A and Gb. As a result, the GERAN Radio Resource Control (RRC) protocol 
is based on both the GSM Radio Resource (RR) and the UTRAN RRC specifications. The MS 
can operate in either the A/Gb mode or the Iu mode. The A/Gb mode is defined for the MS when 
connected to a GERAN with no Iu interface towards the CN. The Iu mode is defined for the MS 
when connected to a GERAN with Iu interfaces towards the CN. 

UMTS has a standardized relocation procedure that is expected will be used as well in the 
30 GERAN Iu mode. Figs. 1 and 2 illustrate the relocation procedure, and can be found as well in 
the standard 3G TS 23.060, V4.2.0 (2001-10), Third Generation Partnership Project; Technical 
Specification Group Services and System Aspects; General Packet Radio Service (GPRS); 
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Service Description; Stage 2 (Release 4). More specifically, Fig. 2 shows the operation of the 
currently specified Combined Hard Handover and SRNS Relocation procedure for the PS 
domain. The illustrated sequence is valid for both intra-SGSN SRNS relocation and for inter- 
SGSN and SRNS relocation. Fig. 3 shows the operation of a Combined Cell /URA Update and 
5 SRNS Relocation procedure for the PS domain. This sequence is valid for both intra-SGSN 
SRNS relocation and for inter-SGSN SRNS relocation. The Cell Update and Relocation 
procedures have been accepted by standardization committees to be adopted from UTRAN to 
GERAN Iu mode. 

According to current GSM specifications (Release 1998 (R98) and Release 1999 (R99), GSM 
03.71), the E-OTD and GPS MS positioning procedures are terminated in the case of handover, 
or upon the occurrence of some other RR management procedure. More specifically, what is 
currently specified is that: 

The BSC shall terminate any network or MS positioning procedure or any 
transfer of RRLP assistance data already in progress if inter-BSC or inter-MSC 
handover is needed and is not precluded by the particular location procedure and 
its current state. 

The BSC shall terminate any network or MS positioning procedure or any 
transfer of RRLP assistance data already in progress if an intra-BSC handover or 
other intra-BSC RR management procedure is needed and is not precluded by the 
particular location procedure and its current state. 

As may be appreciated, the current approach results in GPS and E-OTD positioning procedures 
being terminated in many cases due to HO or some other RR procedure, requiring the VMSC 
(or the GMLC) to restart the MS positioning procedure. This results in additional delays, as well 
as in an increased MS power consumption, and the in some cases the entire positioning operation 
may fail within the time specified by an application. 

SUMMARY OF THE PREFERRED EMBODIMENTS 

The foregoing and other problems are overcome, and other advantages are realized, in 
accordance with the presently preferred embodiments of these teachings. 

35 

These teachings pertain to Assisted GPS, E-OTD and other suitable location methods and 



5 

systems and provide a technique to avoid undesired termination of a LCS procedure due to some 
RR procedure (e.g., HO or CRS). The LCS process and the supplying of its associated 
parameters are moved when required from a current serving BSC/RNC/SMLC and MSC/SGSN 
to a new serving entity with a relocation procedure. These teachings are applicable, for example, 
5 to GERAN Iu mode standards as well as to UTRAN standards, and may be applied as well to 
the GERAN A/Gb mode, while possibly requiring a new interface between BSCs (comparable 
to the Iur-g interface in the Iu mode) when operating in the A/Gb mode. 

A method is disclosed for operating a mobile station in cooperation with a network operator, as 
is a system including the mobile station and the network operator. The method operates, upon 
an occurrence of a RR procedure, including HO and CRS, that affects the mobile station, to 
determine if a location procedure is ongoing in the mobile station and, if it is, to complete the 
location procedure and to report the measurement results (which may be a failure indication) in 
a message from the mobile station to a target radio network controller. The location procedure 
can be, in accordance with an embodiment of this invention, a LCS procedure that is executed 
during a Combined Hard Handover and SRNS Relocation procedure, for both the PS and CS 
domains, and applies to both intra-SGSN/MSC SRNS relocation and inter-SGSN/MSC and 
SRNS relocation. The location procedure can also be, in accordance with another embodiment 
of this invention, a LCS procedure that is executed during a Combined Cell/URA Update and 
SRNS Relocation procedure for the PS domain, and also applies to both intra-SGSN SRNS 
relocation and for inter-SGSN SRNS relocation 

For the LCS procedure, the method further sends LCS parameters from a source RNC/BSC to 
the target RNC/BSC . The LCS parameters in this case are sent in a Source RNC to Target RNC 

25 Transparent Container in a Relocation Required message (note should be made that the name 
of this container is UTRAN specific, and that it may be referred to differently in, for example, 
GERAN). LCS parameters may also be sent from the source BSC/RNC to the target BSC/RNC 
in a Relocation Commit (SRNS Contexts) message or, if no Iur(-g) is available, in a Forward 
SRNS Context message. Note in this case that the reference to Iur-g is GERAN specific, but 

30 should not be viewed as being a limitation upon the practice of this invention. 

The LCS parameters can include at least one of (i) a requested location accuracy; (ii) a requested 



location response time; (iii) details pertaining to a currently ongoing location process; and (iv) 
a GMLC address. 

The measurement results message may be sent by the mobile station before or after sending a 
5 GERAN/UTRAN Mobility Information Confirm message from the mobile station to the target 
BSC/RNC. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 The foregoing and other aspects of these teachings are made more evident in the following 
Detailed Description of the Preferred Embodiments, when read in conjunction with the attached 
Drawing Figures, wherein: 

Fig. 1 is a block diagram of a wireless communications system that is suitable for practicing 
15 these teachings; 

Fig. 2 illustrates the operation of a conventional Combined Hard Handover and SRNS 
Relocation procedure for the PS domain, where the illustrated sequence is valid for both intra- 
SGSN SRNS relocation and for inter-SGSN and SRNS relocation; 

20 

Fig. 3 illustrates the operation of a conventional Combined Cell/URA Update and SRNS 
Relocation procedure for the PS domain, where the illustrated sequence is valid for both intra- 
SGSN SRNS relocation and for inter-SGSN SRNS relocation; 

25 Fig. 4 illustrates the operation of the relocation procedure with LCS data for the case of Cell 
Reselection (PS domain) in accordance with the teachings of this invention; and 

Fig. 5 is a logic flow diagram that illustrates an LCS Relocation in an IP RAN architecture in 
accordance with a further aspect of these teachings. 

30 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



Referring first to Fig. 1, there is illustrated a simplified block diagram of an embodiment of a 
wireless communications system 5 that is suitable for practicing this invention. The wireless 
5 communications system 5 includes at least one mobile station (MS) 100, also referred to herein 
as User Equipment (UE). Fig. 1 also shows an exemplary network operator having, for example, 
a Serving GPRS Support Node (SGSN) 30 for connecting to a telecommunications network, 
such as a Public Packet Data Network or PDN, at least one base station controller (BSC) 40, and 
a plurality of base transceiver stations (BTS) 50 that transmit in a forward or downlink direction 
10 both physical and logical channels to the mobile station 1 00 in accordance with a predetermined 
air interface standard. A reverse or uplink communication path also exists from the mobile 

0 station 100 to the network operator, which conveys mobile originated access requests and traffic. 

O 

1 j When the MS 1 00 moves from a cell served by a first BTS 50 to a cell served by another BTS 
JO 15 50, when both are controlled by the same BSC 40, an inter-BSC handover (HO) is executed. 
T However, the MS 100 may also transition between cells served by BTS s 50 that are individually 
P controlled by different BSCs 40. In this case the HO is considered to be an intra-BSC HO. 

u 

— The air interface standard can conform to any suitable standard or protocol, and may enable both 
™ 20 voice and data traffic, such as data traffic enabling Internet 70 access and web page downloads. 
In the presently preferred embodiment of this invention the air interface standard is a Time 
Division Multiple Access (TDMA) air interface that supports a GSM or an advanced GSM 
protocol and air interface, although these teachings are not intended to be limited to TDMA or 
to GSM or GSM-related wireless systems. 

25 

The network operator may also include a suitable type of Message Center (MC) 60 that receives 
and forwards messages for the mobile stations 100. Other types of messaging service may 
include Supplementary Data Services and one under currently development and known as 
Multimedia Messaging Service (MMS), wherein image messages, video messages, audio 
30 messages, text messages, executables and the like, and combinations thereof, can be transferred 
between the network and the mobile station 100. 
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The mobile station 100 typically includes a microcontrol unit (MCU) 120 having an output 
coupled to an input of a display 140 and an input coupled to an output of a keyboard or keypad 
160. The mobile station 100 may be a handheld radiotelephone, such as a cellular telephone or 
a personal communicator. The mobile station 100 could also be contained within a card or 
5 module that is connected during use to another device. For example, the mobile station 1 0 could 
be contained within a PCMCIA or similar type of card or module that is installed during use 
within a portable data processor, such as a laptop or notebook computer, or even a computer that 
is wearable by the user. 

The MCU 120 is assumed to include or be coupled to some type of a memory 130, including a 
read-only memory (ROM) for storing an operating program, as well as a random access memory 
(RAM) for temporarily storing required data, scratchpad memory, received packet data, packet 
data to be transmitted, and the like. A separate, removable SIM (not shown) can be provided as 
well, the SIM storing, for example, a preferred Public Land Mobile Network (PLMN) list and 
other subscriber-related information. The ROM is assumed, for the purposes of this invention, 
to store a program enabling the MCU 120 to execute the software routines, layers and protocols 
required to implement the improved MS LCS procedure n accordance with these teachings, as 
well as to provide a suitable user interface (UI), via display 140 and keypad 160, with a user. 
Although not shown, a microphone and speaker are typically provided for enabling the user to 
conduct voice calls in a conventional manner. 

The mobile station 100 also contains a wireless section that includes a digital signal processor 
(DSP) 180, or equivalent high speed processor or logic, as well as a wireless transceiver that 
includes a transmitter 200 and a receiver 220, both of which are coupled to an antenna 240 for 
25 communication with the network operator. At least one local oscillator (LO) 260, such as a 
frequency synthesizer, is provided for tuning the transceiver. Data, such as digitized voice and 
packet data, is transmitted and received through the antenna 240. 

It has been realized that the termination of the positioning procedure is in most cases 
30 unnecessary, but may be required, as the MS 100 is expected to behave in the same manner for 
both intra-BSC and inter-BSC HOs, i.e., the MS 100 does not typically know a priori when the 
BSC 40 will be changed during the HO procedure. In all cases in the following Table the 
positioning procedure is terminated according to current specifications. In the Table are also 
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listed what kind of effects the HO or other RR procedure has on the LCS, and what is required 
to be done in order to continue the LCS procedure. 



Positioning method 


RR Procedure 


Effect on positioning 
measurement process 


Actions required to 
continue positioning 
procedure 


(Assisted) GPS 


Inter MSC/SGSN 
handover/CRS 


None*# 


New serving BSC/SMLC 
and MSC/SGSN needs to be 
informed about the ongoing 
positioning procedure and its 
parameters (or the MS's 
response should be send to 
previous SMLC and 
MSC/SGSN). 


Inter BSC 

handover/CRS (Intra 
MSC or SGSN) 


New serving BSC/SMLC 
needs to be informed about 
the ongoing positioning 
procedure and its parameters 
(or the MS's response should 
be send to old SMLC). 


Intra BSC 
handover/CRS 


Nothing 


Other RR management 
procedure (=Intra Cell 
procedure) 


None 


Nothing 



10 







Inter MSC/SGSN 


Assistance data 


New serving BSC/SMLC 






handover/CRS 


delivered to MS is not 
valid anymore. But 
there is possibility that 
the MS has already 
managed to make the 
majority of the 


and MSC/SGSN needs to be 
informed about the ongoing 
positioning procedure and its 
parameters (or the MS's 
response should be send to 
old SMLC and MSC/SGSN). 






Inter BSC 

handover/CRS (Intra 


measurements, or MS 
can internally convert 
the assistance data to 
new serving BTS, and 
the amount of new 
neighbor BTSs is small, 
in these cases it would 


New serving BSC/SMLC 
needs to be informed about 


o 


E-OTD 


MSC or SGSN) 


the ongoing positioning 
procedure and its parameters 
(or the MS's response should 
be send to the previous 
SMLC). 






be still possible to 








Intra BSC 


continue the 


Nothing 


W 

ya 




handover/CRS 


measurement procedure 










in MS under the new 




rn 

~" 
o 






serving BTS. # 




1=4 

u 




Other RR management 


None 


Nothing 


Q 




procedure (=Intra Cell 






fy 




procedure) 







*Note: this assumes that either GSM to GPS time relation is not included to the assistance data, 
or the MS manages to utilize the GSM to GPS time relation in the previous cell before the 
5 occurrence of the HO. 

#Note: The standard should allow the MS to send either the measurement response (with valid 
measurement data), or an error indication (in case the MS cannot perform satisfactory 
measurements under the new serving BTSs). 

10 In order to avoid termination of an ongoing LCS procedure due to an occurrence of some RR 
procedure (e.g. HO or CRS), the LCS process (with the required parameters) is preferably 
continued from the current serving BSC/RNC/SMLC and MSC(server)/SGSN to the new serving 
entities with a relocation procedure. It is noted that for the case of intra-BSC procedures this is 



11 

not required, but the termination of the LCS procedure was not avoidable in R98 and R99 as the 
MS 100 was required to behave in some predictable manner irrespective of whether there is an 
inter-BSC/CRS or intra-BSC handover/CRS. 

It is preferred that the positioning procedure never be terminated in the case of HO, CRS or some 
5 other RR procedure, if the measurement command has been delivered successfully to the MS 
100. If the HO or CRS should occur during the transfer of a measurement command (or 
assistance data) to the MS 100 the positioning procedure may be terminated, or it may be 
continued, possibly at the choice of the network operator. 

10 Relocation Procedure with LCS Data 

Fig. 4 provides an example of the relocation procedure with LCS data for the case of the Cell 
Reselection (PS domain) in accordance with an aspect of this invention. Fig. 4 maybe contrasted 
with the conventional procedure depicted in Fig. 3. In Fig. 4, the MS 100 can be seen to perform 
a cell update in the new cell first, and after that to send a response to the GPS/E-OTD 

15 measurement command (see Step 12X). Other improvements and modifications to the 
conventional Cell Reselection (PS domain) procedure are made apparent in the ensuing 
description of Fig. 4. Note should be made, however, that these teachings are not limited for use 
only with the illustrated Combined Cell/URA/GRA Update and SRNS Relocation procedure for 
the PS domain procedure, but can be applied as well, by example, to the Combined Hard 

20 Handover and SRNS Relocation procedure for the PS domain shown in Fig. 2, and also to the 
Combined Hard Handover and SRNS Relocation procedure for the CS domain. These teachings 
apply as well to LCS Reselection in an IP RAN architecture, as will be discussed below. 

Referring now to the enumerated process steps shown in Fig. 4, a description of each step is now 
25 provided. 

1) After having made cell re-selection, the MS 100 sends a Cell Update/URA/GRA Update 
message to the UTRAN or, in accordance with an aspect of these teachings, to the GERAN. 
Upon reception of the message, the target RNC/BSC forwards the received message towards the 
30 source SRNC via Iur (note that in the following signal flow description a reference to RNC 
denotes as well the BSC for the GERAN case). The source SRNC then decides to perform a 
Combined Cell/URA/GRA Update and SRNS Relocation towards the target RNC. 
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2) The source SRNC initiates the relocation preparation procedure by sending a Relocation 
Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to Target RNC 
Transparent Container) to the old (previous) SGSN. The source SRNC sets the Relocation Type 
to "UE not involved". The Source RNC to Target RNC Transparent Container includes the 
5 necessary information for Relocation co-ordination, security functionality, and RRC protocol 
context information (including UE Capabilities). 

In accordance with an aspect of this invention, the LCS parameters (e.g., requested LCS QoS, 
what positioning procedure is active, details of the currently ongoing location process, GMLC 
10 Address of the active positioning procedure) may be included in the Relocation Required 
message in the Source RNC to Target RNC Transparent Container. Note in this regard that the 
LCS QoS includes, for example, the required location accuracy and the response time. Another, 
less preferred technique is described below with respect to Step 7. 

15 3) The old SGSN determines from the Target ID if the SRNS Relocation is an intra-SGSN SRNS 
relocation or an inter-SGSN SRNS relocation. In case of inter-SGSN SRNS relocation the old 
SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation 
Request (IMSL Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target 
Identification, UTRAN Transparent Container, RANAP Cause) message to the new SGSN. At 

20 the same time a timer is started on the MM and PDP contexts in the old SGSN, as specified in 
the Routeing Area Update procedure in the subclause Location Management Procedures (UMTS 
Only) found in 3G TS 23.060. The Forward Relocation Request message is applicable only in 
the case of the inter-SGSN SRNS relocation. 

25 4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, 
CN Domain Indicator, Source RNC to Target RNC Transparent Container, RABs To Be Setup) 
to the target RNC. For each RAB requested to be established, RABs To Be Setup contain 
information such as RAB ID, RAB parameters, Transport Layer Address and Iu Transport 
Association. The RAB ID information element contains the NSAPI value, and the RAB 

30 parameters information element gives the QoS profile. The Transport Layer Address is the 
SGSN Address for user data, and the Iu Transport Association corresponds to Tunnel Endpoint 
Identifier Data. 
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After all necessary resources for accepted RABs, including the Iu user plane, are successfully 
allocated, the target RNC sends the Relocation Request Acknowledge (RABs setup, RABs 
failed to setup) message to the new SGSN. The target RNC, for each RAB to be setup (defined 
by an IP Address and a Tunnel Endpoint Identifier), receives both forwarded downstream PDUs 
5 from the source SRNC as well as downstream PDUs from the new SGSN. 

5)When resources for the transmission of user data between the target RNC and the new SGSN 
have been allocated, and the new SGSN is ready for relocation of SRNS, the Forward Relocation 
Response message (Cause, RANAP Cause, and Target RNC Information) is sent from new 
10 SGSN to old SGSN. This message indicates that the target RNC is ready to receive from the 
source SRNC the downstream packets not yet acknowledged by the MS 100, i.e., the relocation 
H resource allocation procedure is terminated successfully. RANAP Cause is information from the 
S target RNC to be forwarded to the source RNC. The RAB Setup Information, one information 
element for each RAB, contains the RNC Tunnel Endpoint Identifier and RNC IP address for 
3 15 data forwarding from the source SRNC to target RNC. If the target RNC or the new SGSN failed 
~ to allocate resources the RAB Setup Information element contains only the NSAPI indicating 
3 that the source RNC is to release the resources associated with the NSAPI. The Forward 
2 Relocation Response message is applicable only in the case of inter-SGSN SRNS relocation. 

Q 20 6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs 
5 " to be released, and RABs subject to data forwarding) message to the source SRNC. The old 
SGSN determines the RABs subject to data forwarding based on QoS, and those RABs are 
contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the 
information element is specified to contain the RAB ID, Transport Layer Address and Iu 
25 Transport Association. The Transport Layer Address and Iu Transport Association is used for 
forwarding of DL N-PDU from the source RNC to the target RNC. 

7) Upon reception of the Relocation Command message from the PS domain, the source RNC 
starts a data-forwarding timer. When the relocation preparation procedure is terminated 
30 successfully, and when the source SRNC is ready, the source SRNC triggers the execution of 
relocation of SRNS by sending a Relocation Commit (SRNS Contexts) message to the target 
RNC. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the 
target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence numbers 
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of the GTP-PDUs next to be transmitted in the uplink and downlink directions, and the next 
PDCP sequence numbers that would have been used to send and receive data from the MS 100. 
For connections using the RLC unacknowledged mode the PDCP sequence number is not used. 

5 hi accordance with these teachings, and as was discussed above in Step 2, the LCS parameters 
may be included in the Relocation Commit message, although this technique is not presently 
more preferred than including the LCS parameters in the Relocation Required message in the 
Source RNC to Target RNC Transparent Container. 

8) After having sent the Relocation Commit message, the source SRNC begins the forwarding 
of data for the RABs subject to data forwarding. The data forwarding at SRNS relocation is 
carried out through the Iu interface, meaning that the data exchanged between the source SRNC 
and the target RNC are duplicated in the source SRNC and are routed at the IP layer towards the 
target RNC. 

9) The target RNC sends a Relocation Detect message to the new SGSN when the relocation 
execution trigger is received. For the SRNS relocation type UE Not Involved, the relocation 
execution trigger is the reception of the Relocation Commit message from the Iur interface. 
When the Relocation Detect message is sent, the target RNC starts SRNC operation. 

10) After having sent the Relocation Detect message, the target SRNC responds to the MS 100 
by sending a Cell Update Confirm/URA/GRA Update Confirm message. Both messages contain 
UE information elements and CN information elements. The UE information elements include 
among other information the new SRNC identity and S-RNTI. The CN information elements 
contain among other information the Location Area Identification and Routing Area 
Identification. This procedure is co-ordinated in all Iu signalling connections existing for the MS . 

1 1) Upon reception of the Relocation Detect message, the CN may switch the user plane from 
the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation, 

30 the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN 
Tunnel Endpoint Identifier, QoS Negotiated) to the GGSNs concerned. The GGSNs update their 
PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint 
Identifier) message. 
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12) When the MS 1 00 has reconfigured itself, it sends the RNTI Reallocation Complete message 
to the target SRNC. 

12X) In accordance with these teachings, if some positioning procedure was ongoing in the MS 
5 100, the MS 100 sends the response message including successful measurement reports or a 
failure indication. The message may be sent before of after sending the RNTI Reallocation 
Complete message. In this manner the ongoing MS 100 positioning procedure is not required to 
be terminated, thereby overcoming the problems that were discussed above. The measurement 
results message may be sent by the mobile station before or after sending a GERAN/UTRAN 
10 Mobility Information Confirm message from the mobile station to the target BSC/RNC. 

H 13) When the target SRNC receives the RNTI Reallocation Complete message, i.e., the new 
8 SRNC-ID + S-RNTI are successfully exchanged with the UE by the radio protocols, the target 
£ SRNC initiates the Relocation Complete procedure by sending the Relocation Complete message 
5 15 to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target 
2 SRNC the completion of the relocation of the SRNS to the CN. If the user plane has not been 
■ switched at Relocation Detect, the CN upon reception of Relocation Complete switches the user 
U plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS 
relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation 
Q 20 procedure by sending a Forward Relocation Complete message. 

1 4) Upon receiving the Relocation Complete message, or if it is an inter-SGSN SRNS relocation; 
the Forward Relocation Complete message, the old SGSN sends an Iu Release Command 
message to the source RNC. When the RNC data-forwarding timer started in Step 7 expires the 

25 source RNC responds with an Iu Release Complete. 

1 5) After the MS 1 00 has finished the Cell/URA/GRA update and RNTI reallocation procedure, 
and if the new Routing Area Identification is different from the old, the MS 100 initiates the 
Routing Area Update procedure. See in the regard the subclause Location Management 

30 Procedures (UMTS Only). Note that it is only a subset of the RA update procedure that is 
performed, since the MS 100 is in the PMM-CONNECTED state. 
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LCS Relocation in IP RAN Architecture 



A discussion is now made of the positioning signaling flow in a particular IP RAN architecture. 
Reference can also be made to Fig. 5 for a discussion of the positioning signaling flow. 

5 

It should be noted, however, that this procedure need not be IP RAN specific, and could be 
employed as a normal positioning procedure in UTRAN (or GERAN) by replacing references 
to Radio Network Access Server (RNAS) with RNC. It should be noted that the RNAS 
functionality can be integrated into the BTS functionality. 

10 

1) The SGSN/MSC server sends a Location Request to the RNAS. 

2) The RNAS knows in which cell the MS 1 00 is located, or pages the MS 1 00 to determine the 
current cell where the MS 100 is located. If the Location Request only requires the service area 

15 id the RNAS may send this directly to the SGSN/MSC server without involving the SMLC. 

3) The RNAS sends a Location Request to the SMLC. The SMLC determines if the cell accuracy 
(with possible other available information, such as the current Timing Advance value and the 
received signal level) is sufficient, and then translates the cell id (and possibly the other avaiable 

20 information) into MS 1 00 location coordinates. If better accuracy is required, the SMLC requests 
the RNAS to obtain measurement results of the target MS 100. 

4) The RNAS sends a measurement request to the target MS 100. 
25 5) The target MS 100 sends the measurement results to the RNAS. 

6) The RNAS sends the measurement results to SMLC. 

7) The SMLC requests measurement results from the LMU (or the LMU reports periodically to 
30 the SMLC, in which case this step and the next step (8) can be omitted). 

8) The LMU sends the measurement results to the SMLC 
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9) The SMLC calculates the location of the target MS 100. 

10) The SMLC sends the location calculation results to the RNAS. 

5 11) The RNAS sends the location result to the SGSN/MSC server. 

The IP RAN Architecture has some effect on the LCS relocation procedure in the HO/CRS case, 
hi the IP RAN architecture the SMLC and possibly the RNAS may be maintained the same 
during the positioning procedure regardless of the HO or CRS (i.e., the occurrence of the HO or 

10 CRS does not require a change in the RNAS or the SMLC). This means that in the IP RAN 
architecture the relocation procedure with the transfer of the LCS parameters is not required, if 
the RNAS is not changed. In the case where the RNAS is changed, the SMLC would still be the 
same, and in this case the new RNAS is required to find the SMLC. This can be accomplished 
if during the relocation procedure the address of the SMLC is transported from the old RNAS 

15 to the new RNAS. 

It should be noted that absent the use of this invention the MS 100 will always abort the 
positioning procedure in the case of HO or CRS. This applies as well to the IP RAN architecture 
discussed above. 

20 

It should be appreciated that the improved LCS procedure in accordance with these teachings 
does not prematurely terminate as often as in the prior art due to an occurrence of some HO, 
CRS, or other RR procedure, and thereby provides reduced average delays, lower power 
consumption in the MS 100, and improved service to the end user. 

25 

While described in the context of presently preferred and exemplary embodiments of these 
teachings, those skilled in the art will recognize that changes in form and details may be made, 
and that these changes will still fall within the scope of these teachings. 



